[MKVToolnix] Cutting and rejoining videos with audio causes a discrepancy

[Compositor]

MKVToolnix has been my go-to tool for muxing mkv video files for over a decade. There is one quirk with it that bothers me and I wonder if anyone can help me with it, or can suggest another tool that gets around it.

It's like this, take a video file that has an audio stream. Use mkvtoolnix to mux it into an mkv file and cut it into two pieces. Then, rejoin the two pieces, at the point where they were cut. You would assume you'd get the same video as the original, correct? Not quite.

Another tool I use frequently is Aegisub, for editing subtitles. Its video player is capable of show the timecode (timestamp?) of each frame of video that it is playing to the milisecond. When I use Aegisub to look at both the original and rejoined videos, there is a difference. Let's say the video was cut at frame 101. On the rejoined video, frame 101 could be 10 to 40+ miliseconds off compared to its original position.

This only happens when the video has an audio stream. If the video has no audio stream, there's no discrepancy on rejoining. Not more than 1 or 2 ms that I feel is caused by an unrelated matter anyway. So I'm sure the audio stream is the cause. Since I because aware of this quirk, I have avoided joining videos with audio streams together.

But today, I met a situation where I had to cut part of an audio stream and rejoin it to its original. When the task was complete, there was a displacement of 11 ms. A quarter of a frame at the framerate of the video, I considered that acceptable under the circumstances.

Still, I would like to know, is there a way to do better?

[sekininsha]

Use mkvtoolnix to mux it into an mkv file and cut it into two pieces. Then, rejoin the two pieces, at the point where they were cut. You would assume you'd get the same video as the original, correct? Not quite.

maybe this is because you don't cut in a Key-frame

Another tool I use frequently is Aegisub, for editing subtitles. Its video player is capable of show the timecode (timestamp?) of each frame of video that it is playing to the milisecond. When I use Aegisub to look at both the original and rejoined videos, there is a difference. Let's say the video was cut at frame 101. On the rejoined video, frame 101 could be 10 to 40+ miliseconds off compared to its original position.

If the frame 101 is not a Key-frame the cut is made in the closest key-frame.

But today, I met a situation where I had to cut part of an audio stream and rejoin it to its original. When the task was complete, there was a displacement of 11 ms. A quarter of a frame at the framerate of the video, I considered that acceptable under the circumstances.

.. did you apply a negative delay here?

[Compositor]

maybe this is because you don't cut in a Key-frame

I do cut on key frames. Aegisub is also a good tool for locating keyframes to make cuts.

... did you apply a negative delay here?

I did not, but stream info readers and stream extractors do indicate the audio stream has a delay within the video file. When cut, the cut segment also has an additional delay. I have no way of knowing if the delay should be there.

[sneaker]

This only happens when the video has an audio stream. If the video has no audio stream, there's no discrepancy on rejoining. Not more than 1 or 2 ms that I feel is caused by an unrelated matter anyway. So I'm sure the audio stream is the cause. Since I because aware of this quirk, I have avoided joining videos with audio streams together.

See mkvmerge docs about --append-mode and keep in mind audio and video frames usually don't align perfectly.

Also note:
- mkvmerge cutting is not safe in regards to non-IDR seeking points.
- mkvmerge does not cut in the middle of a subtitle (at least for text subtitles)

[Compositor]

See mkvmerge docs about --append-mode and keep in mind audio and video frames usually don't align perfectly.

I don't suppose you know how to change the append mode without resorting to commandline?
I have imagined the audio track jutting out a bit at the cut point on both segments too.

- mkvmerge cutting is not safe in regards to non-IDR seeking points.

What are IDR seeking points?

- mkvmerge does not cut in the middle of a subtitle (at least for text subtitles)

I've looked at subs where a text line straddled a cut. That line still contains the original end time for the line, which is now beyond the end of the video. If you joined another video to this one, the first frame of the next video segment would be after the end of that text line. An effect of the file-type append, I suppose.

[sneaker]

I don't suppose you know how to change the append mode without resorting to commandline?

You can add --append-mode track to the miscellaneous field in the output tab. (This is not a magic fix for splitting on non-IDR frames or in the middle of text subtitles.)